In parallel to the growth in use of online channels for accessing a variety of services, and performing a variety of transactions, identity theft has reached epidemic levels, and online account takeover and transaction fraud is growing at an enormous rate. Parties committing fraud (“fraudsters”) have new technologies at their disposal: for example “Trojan horses” and key loggers may be installed in unsuspecting customers' computers, transmitting personal information back to the fraudster; and phishing attacks may trick consumers into giving up personal and financial information (for example without limitation: social security number (“SSN”), account numbers, banking information, user names and passwords for various services, personal identification numbers (“PINs”), credit card numbers, which may be referred to as for example “user Credentials” or “Credentials”).
Recent scams show a sophisticated, determined, innovative and well organized online crime wave. Fraudsters are more adaptive than ever, modifying their modus operandi and techniques quickly to exploit new vulnerabilities. While the fraudsters do not limit themselves to a specific sector, their main focus is on the banking and financial accounts sectors (other sectors prone to fraud are government services, ISPs, telecom companies and healthcare and many others).
One issue is authentication—how does a service or transaction provider know whether a certain user accessing a service and performing actions at a certain site is who he or she claims to be. Using the combination of a login and password alone (which still are the most prevalent method of authentication) may not be satisfactory.
Many solutions have been proposed for the problem of authentication, however many of them encounter an imbalance between usability vs. security: they are either not secure enough, or, when security is enhanced to satisfactory levels, they are cumbersome and expensive to deploy and operate.
Various service providers may use Credentials in order to authenticate users in remote applications. Authentication may be required whenever a sensitive operation takes place, for example, viewing personal information, performing financial transactions, updating the user's profile and more.
During authentication the user may usually be required to supply a pre-established password and optionally an additional shared secret between the user and the service provider. Users' credentials may enable access to sensitive information as well as funds, and therefore getting hold of them has become a popular criminal activity Stealing users' credentials may be done in various ways. For example, theft of a file containing credentials from the bank or a third party (including an “inside job”), a large and successful “Phishing” attack, keyboard sniffing and more.
When faced with a major theft of user credentials, the service provider may execute one or more of the following options:
Provider may operate its business at a much higher risk level, for example, may check and analyze transactions to make sure no fraudulent activity takes place.
Provider may perform a costly operation of changing the user credentials or deploying a new authentication mechanism.
Provider may shut down parts of the business in case the other two options may not be acceptable.
Provider may perform other sets of actions.
The service provider may not have any external alert as to the occurrence of a massive credential theft. For example, it may not know when a large set of credentials is stolen by an insider job, or from a third party service provider. In addition, even when a large theft may be known, like in the case of a large phishing attempt, the service provider may not know when the stolen credentials will actually be used.
Service providers may be therefore looking for alternative authentication options. Some of the alternative solutions offered today are:
1. Provider may ask for shared secret information that changes over time and may be therefore more difficult to obtain or that may lose its value after some time, as it becomes irrelevant, for example, details about recent transactions, or invoicing.
2. Provider may ask for random parts of shared secret information, for example, random digits of the password, or random data elements out of a set of known data elements
3. Mobile or telephone authentication, for example, mobile telephone may be pre-registered to the service and may be used to authenticate the user
4. Token based authentication
The current solutions may not be satisfactory, since none of them may strike a good balance between security and usability. Either they may not be secure enough, for example, asking for random pieces of a shared secret, information which may easily be obtained during the initial user credentials theft, may not be usable enough or may be too expensive to actually deploy, for example, token authentication which may be expensive to implement, may require customer education, and deployment ahead of time to all users.